IBIS Macromodel Task Group

Meeting date: 2 June 2015

Members (asterisk for those attending):
ANSYS:                      * Dan Dvorscak
                            * Curtis Clark
Avago (LSI)                   Xingdong Dai
                            * Bob Miller
Cadence Design Systems:       Ambrish Varma
                              Brad Brim
                              Kumar Keshavan
                              Ken Willis
eASIC                         David Banas
                              Marc Kowalski
Ericsson:                     Anders Ekholm
IBM                           Steve Parker
Intel:                      * Michael Mirmak
Keysight Technologies:      * Fangyi Rao
                            * Radek Biernacki
                              Nicholas Tzou
Maxim Integrated Products:    Hassan Rafat
Mentor Graphics:            * John Angulo
                            * Arpad Muranyi
Micron Technology:          * Randy Wolff
                              Justin Butterfield
QLogic Corp.                  James Zhou
                              Andy Joy
SiSoft:                     * Walter Katz
                              Todd Westerhoff
                            * Mike LaBonte
Synopsys                      Rita Horner
Teraspeed Consulting Group:   Scott McMorrow
Teraspeed Labs:             * Bob Ross
TI:                           Alfred Chong

(Note: Agilent has changed to Keysight)

The meeting was led by Arpad Muranyi.

------------------------------------------------------------------------
Opens:

- Curtis Clark to take the minutes.

--------------------------
Call for patent disclosure:

- None


-------------
Review of ARs:

- Walter to send AMI directionality recommendations from previous meeting to
  the list.
  - Done.

-------------
New Discussion:

- Arpad: Michael M., would you like to discuss the directionality BIRD?

- Michael M: Yes.
  - I would like to request that the document I sent out be available on the
    work archive site.
    - AR: Mike LaBonte to post it.
  - Thank you everyone for all the feedback.
  - Big changes in this version.
  - Added the Executable_Tx and Executable_Rx.
  - Removed the direction parameter.
  - Reintroduced the one [Algorithmic Model] keyword per [Model] restriction.
  - Changed the Title to better reflect the final proposal.
  - Changed the Statement of Issue based on Bob Miller's comments.
  - This version adds Executable_Tx and Executable_Rx to [Algorithmic Model].
  - Requirement: I/O type models must have at least one Executable_Tx and at
    least one Executable_Rx Sub-Params.
  - Their fields are identical to the existing Executable Sub-Param.
  - Revised the tables re: reserved parameters and their directionality.
  - Examples changed.
  - Should we allow Executable_Tx for 3-State [Model] types?
    - It could be clear from context if we just keep the existing Executable.
  - Bob: I prefer using Executable only.
    - If you have Executable_Tx, then this 3-State type becomes an exception
      in that it has no Executable_Rx.
    - Would simplify the parser's job.
- Michael M: No problem, I understand.  I'm happy either way.
- Walter: Implication here is that if you have an I/O you need a Tx and an Rx?
- Michael M: Correct, you need at least one Executable_Tx and Executable_Rx.
- Walter: Say I have a DDR4 DQ on a controller.
  - It might have Tx equalization, and it might not.
  - It might have Rx equalization, and it might not.
  - So it could have just Tx or just Rx equalization.
  - That was the impression I got from some statements you [Michael M.] made
    about the application of this to DDR4 controller buffers.
  - Did I understand that correctly?
- Michael M: Yes, it is possible to just have one.
- Walter: In that case, I think we should allow either one or both.
- Michael M: In that case, we are setting up a situation where:
  - If Executable_Tx exists, but Executable_Rx does not exist then we are only
    using the analog portion of the buffer in the simulation for Rx simulation.
- Walter: For a controller example:
  - Reads might have equalization if you have a CTLE or DFE.
  - Writes may not if it did not have an FFE.
  - Writes would be analyzed the traditional IBIS way.
- Michael M: Okay.  That's a fairly easy change to make.
- Walter: One other comment:
  - I thought last week we agreed to use Executable underscore Tx [these minutes
    have used this form - Executable_Tx, Executable_Rx].
- Arpad: Walter is correct.
- Michael M: [will change BIRD to add the underscore]
- Bob: I hear Walter's point.
  - But what would be the problem of having Executable_Tx and Executable_Rx if
    one is a straight-through no equalization?
- Walter: If you have an AMI model, the implication is AMI processing.
  - In the example I gave the Tx may not have an FFE.
  - So in that direction you don't want to do writes statistically with AMI.
  - Want traditional modeling in that case.
- Radek: Question is does the flow for AMI processing need to be addressed?
  - Does AMI flow need to be augmented to support such a situation?
- Michael M: Yes.
  - Because the request here is to ensure the language supports it.
- Arpad: Isn't that a tool vendor decision?
- Radek: We have a clearly defined flow that doesn't address this situation.
  - Yes, tool can handle it.  But we have a flow.
- Bob: The flow question is a relevant question.
- Arpad: Flow outlines the order things are executed and things pass in and out.
  - I don't think it is this BIRD's issue.
  - You could set up a simulation with AMI on one side and regular IBIS on the
    other without this BIRD.
- Bob: It's relevant to whether we should force Executable_Tx and Executable_Rx.
  - It's within the AMI flow.
- Michael M: Would resolving that be a block to approving this BIRD?
- Arpad: That was my point.
  - It seems an open question with or without this BIRD.
  - We shouldn't force an I/O to have both if it doesn't have the functionality.
  - I don't see an issue with correcting that so both are not required.
  - Let's make sure this rule wouldn't be misinterpreted for the flow.
- Radek: If we don't require both, it is still okay.
  - We are only using one flow direction at a time.
  - I think relaxing this requirement is okay.
- Michael M: I have 3 changes to make to the draft.
  - Introduce the "_" characters.
  - Allow Executable_Tx or Executable_Rx or both.
  - 3-State models can't use Executable_Tx (only Executable).
- Arpad: Motion to submit with those changes and recommend approval.
- Mike L: Second.
- Arpad: Anyone opposed? [none opposed]

Enhanced C_comp modeling:
- Arpad: Randy, would you like to discuss the C_comp proposal?
- Randy: Would be nice if people could read it again and give me more feedback.
- Arpad: Let's recap.
- Randy: I think I'm at draft 6 [which is currently posted].
  - Idea is to replace C_comp with improved modeling capability.
    - IBIS-ISS or touchstone files to describe the capacitance.
  - Ability to pass in some values to the model.
    - Single values or corner values.
  - Several types of models in terms of terminals.
    - C_comp hangs off A_signal terminal and connects to various voltage rails.
    - Another example allows an extra terminal to be brought out for an analog
      receive terminal.
      - Series filtering between die pad and input buffer - extra signal
        could be brought out.
      - C_comp in this case is series, perhaps a series resistance for example.
    - Also, two pseudo-differential buffers with a diff C_comp.
      - Pos and Neg signal terminals.
- Arpad: You don't need the series aspect to do a differential approach, right?
- Randy: Yes.
- Arpad: Would another picture be good for that case?
- Randy: Yes, I'd like to add that picture.
  - [back to reviewing draft]
  - Note about the fact that you have to provide the "N+1" reference terminal
    when using a touchstone file.
  - Required by the BIRD so it doesn't get referenced to node zero or something.
- Arpad: Is it submitted?
- Randy: No.
- Bob: [referring to differential pair series C_comp picture]
  - This implies the receiver is true differential, which means [External Model].
  - I think this figure is wrong.
  - We don't define I-V and K-T, we define I-V and v(t).
- Randy: In the original discussions v(t) came up.
  - v(t) isn't used directly.
  - EDA tools have to figure out a way of de-embedding the C_comp model.
  - Originally did have the buffers labelled as v(t).
- Bob: Do you use K-T in other pictures?  I have concerns about that.
- Arpad: Does the text mention K-T?
  - It doesn't, so in that regard we should just change the drawings.
- Randy: We could use the figures as they are and add a statement regarding K-T.
  - Or we could remove K-T.
- Arpad: I prefer to remove it.
- Walter: [referring to differential picture again]
  - Bob is implying that this applies only to differential [External Model]?
- Arpad: Bob is just objecting to this little true differential triangle shown.
- Walter: I agree the picture is wrong.
  - Why can't this C_comp model work with legacy differentials?
  - Do we want to support a pseudo-differential, two single ended drivers and
    receivers?
- Randy: What I meant to show was more of a pseudo-differential setup.
  - That's why the second buffer is shown as an inverted buffer associated
    through the diff_pin statement.
  - Sort of an implied buffer.  Do we need a dashed line around it?
- Arpad: That is not the issue.
  - I think Bob was commenting on the receiver symbol being only one triangle.
- Randy: You can have that under receiver thresholds if you put in the
         differential receiver threshold keywords.
- Bob: Thresholds, but, we can even do differential timing loads.
  - We added Rdiff and Cdiff.
  - For this figure, we would still apply this as two pseudo-differential
    buffers.
- Arpad: If the triangle represents the I-V and clamp curve based receiver
         model, then I agree it has to be two triangles.
- Bob: There are some syntactical changes relative to the interconnect proposal.
  - May need to update with that stuff.
- Randy: Yes, it's a bit different.
  - I've started to incorporate those changes.
  - Do you think we need to finish the interconnect BIRD before finishing this?
- Bob: Yes, or we will be out of sync.
  - No urgency for this BIRD since it's scheduled for the release after next.
- Randy: Yes.
- Arpad: How different is this from interconnect?
  - Interconnect allows the exact same thing except the new black box would not
    be part of the compensation algorithm.
- Bob: C_comp model can work independent of the interconnect modeling proposal.
- Arpad: Wouldn't it be easier to add this to the interconnect proposal?
  - If we have a box between the pad and the buffer terminal, and the only
    difference is whether the box is part of the compensation algorithm or not?
- Bob: I see your point.
  - I'd prefer to keep them separate so the interconnect BIRD doesn't grow more.
- Arpad: If we keep them separate, we should be careful to keep the same syntax.
- Walter: You're absolutely right.
  - We could take this C_comp circuit and put it into the package model, and you
    could use the optional model name on the terminals, so it would be C_comp for
    a [Model].
  - Inside the [Model] your C_comp keyword would be zero, and your v(t) curves
    then become the K(t) curves.
  - That's a relatively straight forward recommendation.
  - One could generate K(t) curves and then put the C_comp circuit in the package
    model.  It is one way to do it.
- Randy: That's an important point that you'd have K(t) not v(t) in the [Model].
- Arpad: If we're leaning toward waiting until the interconnect is finished,
         should we table this for the time being?
- Randy: I'm okay with that.
- Walter: Motion to table.
- Bob: Second.
- Arpad: Anyone opposed? [none opposed]

- Arpad: I'm hoping next week to get motion on the back channel BIRD.
  - I have two entries for optimization and backchannel topics.
- Walter: My proposal for optimization is a different approach.
  - I believe it is a superset of BIRD147.1.
  - The ball is in Cadence's court.
    - If they're okay with it, then BIRD147.1 gets tabled.
    - If they're not then we have to adjudicate which direction to take.
- Arpad: I'd like to encourage everyone to take it seriously.
  - I'd like to make some progress next week.
- Walter - It's been lingering.
  - No one out there was clamoring for it.
  - That is about to change shortly, so it is timely now.
- Arpad: Thank you all for joining. 
  
-------------
Next meeting: 9 June 2015 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
